This is how the dark theme already looks like:

This how this looks like on macOS before this change

This how this looks like on macOS after this change

I think this also helps a lot for user that have the "Hide icon" setting on the "Appearance" preference page (#1071) turned on.

Test Results

   917 files  ±0     917 suites  ±0   36m 53s ⏱️ - 1m 36s
 7 434 tests ±0   7 282 ✅  - 1  150 💤 ±0  2 ❌ +1 
21 878 runs  ±0  21 493 ✅  - 1  383 💤 ±0  2 ❌ +1 

For more details on these failures, see this check.

Results for commit 271ef9c. ± Comparison against base commit 1472375.

♻️ This comment has been updated with latest results.

@HeikoKlare and @thomasritter: What do you think?

I agree that the proposed behavior is desirable. On Windows, the behavior is already as expected without this PR: hovering over unselected tab items (no matter if the tab folder has focus or not) highlights them. In the following screenshot, I hover over the "Declaration" tab. Note that the color is also lighter than the one selected in this PR:

Unfortunately, with this change, it does now work anymore on Windows. Behavior is then as follows: hovering over a tab item only highlights it if the tab folder does not have focus. And in that case, the highlight color is notably darker than in the current implementation. Again, I hover over the "Declaration" tab:

So there seem to be different theme colors and/or different CSS interpretations at least in the Mac and Windows implementations.

I agree that the proposed behavior is desirable. On Windows, the behavior is already as expected without this PR: hovering over unselected tab items (no matter if the tab folder has focus or not) highlights them. In the following screenshot, I hover over the "Declaration" tab. Note that the color is also lighter than the one selected in this PR:

Can you tell me what color definition is used here?

Unfortunately, with this change, it does now work anymore on Windows. Behavior is then as follows: hovering over a tab item only highlights it if the tab folder does not have focus. And in that case, the highlight color is notably darker than in the current implementation. Again, I hover over the "Declaration" tab:

So there seem to be different theme colors and/or different CSS interpretations at least in the Mac and Windows implementations.

That's strange.
For windows light the following CSS file is used: e4_default_win.css. This includes /css/e4_basestyle.css, which in turn includes /css/light/e4-light_tabstyle.css.
For mac light the following CSS file is used: e4_default_mac.css. This includes /css/e4_basestyle.css, which is the same as for windows.

So the difference has to be in the CSS definitons inside e4_default_win.css. And in this file we have (besides some ColorDefinitions) only this:

.MPartStack {
	swt-simple: true;
}

CTabFolder.MArea {
	background-color: #F0F0F0;
	swt-selected-tab-fill: #F0F0F0;
	swt-unselected-tabs-color: #F0F0F0;
	swt-outer-keyline-color: #F0F0F0;
	swt-inner-keyline-color: #F0F0F0;
	swt-tab-outline: #F0F0F0;
}

CTabFolder Canvas {
	background-color: #F8F8F8;
}

Which of these properties causes the hover-behaviour on windows?

I changed all of them, but none had any effect on the hover behavior. Probaby the hover behavior is simply the default behavior of the OS widget.

But I now found why your proposal "breaks" behavior on Windows: the highlight color you chose is exactly the same as the background color of a tab folder that has focus. You can see that in the following screenshot: in both cases, I hover over the "Declaration" tab. The tab folder at the top has focus, while the one at the bottom has not.

Using the background color for active rather than inactive tabs would fix that. That is actually the color that Windows already uses by default, so it would change nothing on Windows compared to existing behavior.

I tested on Windows and Linux and both look good now 👍 That means: the patch does not change any behavior for these systems, as both Win32 and GTK seem to have the hover highlighting behavior as default.

Just one thing I found when taking another look at the CSS configurations: usually there are color keys "start" and "end", probably in case the theme defines some gradient? E.g.

'#org-eclipse-ui-workbench-ACTIVE_TAB_BG_START' '#org-eclipse-ui-workbench-ACTIVE_TAB_BG_END' 100% 100%;

Maybe the added configuration should also consider that, even though gradients are rather uncommon now?

I tested on Windows and Linux and both look good now 👍 That means: the patch does not change any behavior for these systems, as both Win32 and GTK seem to have the hover highlighting behavior as default.

Just one thing I found when taking another look at the CSS configurations: usually there are color keys "start" and "end", probably in case the theme defines some gradient? E.g.

'#org-eclipse-ui-workbench-ACTIVE_TAB_BG_START' '#org-eclipse-ui-workbench-ACTIVE_TAB_BG_END' 100% 100%;

Maybe the added configuration should also consider that, even though gradients are rather uncommon now?

I also thought about the gradient and explicitly opted against it. It's uncommon in todays UIs. Should we merge this as is?

Comment to the same start and end gradient colour: IIRC the CSS engine only supported gradients hence to remove it I had to set both to the same value. It would better if the css API supports a single colour as we could simplify our CSS files but I never found the time to investigate/ implement this.

Why is the CI build failing now?
Remote call to JNLP4-connect connection from 10.40.66.231/10.40.66.231:56210

Build is failing because of
META-INF/MANIFEST.MF:0 The re-exported type org.eclipse.swt.ole.win32.OLE has been removed from org.eclipse.jface_3.32.0 etc.
These errors also occur in master builds: https://ci.eclipse.org/platform/job/eclipse.platform.ui/job/master/335/console

This is an SWT issue (I will inspect if that's covered by one of the issues processed today).

Build is failing because of META-INF/MANIFEST.MF:0 The re-exported type org.eclipse.swt.ole.win32.OLE has been removed from org.eclipse.jface_3.32.0 etc. These errors also occur in master builds: https://ci.eclipse.org/platform/job/eclipse.platform.ui/job/master/335/console

This is an SWT issue (I will inspect if that's covered by one of the issues processed today).

Thanks for looking into it.

Comment to the same start and end gradient colour: IIRC the CSS engine only supported gradients hence to remove it I had to set both to the same value. It would better if the css API supports a single colour as we could simplify our CSS files but I never found the time to investigate/ implement this.

the property 'swt-unselected-hot-tab-color-background' doesn't support gradients but only a single color
see:

	@Override
	protected void applyCSSProperty(Control control, String property,
			CSSValue value, String pseudo, CSSEngine engine) throws Exception {
		if (!(control instanceof CTabFolder) || value.getCssValueType() != CSSValue.CSS_PRIMITIVE_VALUE) {
			return;
		}

		if (UNSELECTED_HOT_TAB_COLOR_BACKGROUND.equals(property)) {
			Color newColor = (Color) engine.convert(value, Color.class, control.getDisplay());
			CTabFolderRenderer renderer = ((CTabFolder) control).getRenderer();
			if (renderer instanceof ICTabRendering) {
				((ICTabRendering) renderer).setUnselectedHotTabsColorBackground(newColor);
			}
		}
	}

Build is failing because of META-INF/MANIFEST.MF:0 The re-exported type org.eclipse.swt.ole.win32.OLE has been removed from org.eclipse.jface_3.32.0 etc. These errors also occur in master builds: https://ci.eclipse.org/platform/job/eclipse.platform.ui/job/master/335/console

This is an SWT issue (I will inspect if that's covered by one of the issues processed today).

I've reported #1654

Build is failing because of META-INF/MANIFEST.MF:0 The re-exported type org.eclipse.swt.ole.win32.OLE has been removed from org.eclipse.jface_3.32.0 etc. These errors also occur in master builds: https://ci.eclipse.org/platform/job/eclipse.platform.ui/job/master/335/console
This is an SWT issue (I will inspect if that's covered by one of the issues processed today).

I've reported #1654

Thanks.

The two failing tests are already reported in:
#1005
#1427